fix(frontend): auto-retry transient Edge Function failures - #2891
Conversation
Console traffic shares one invocation path (invokeCapgoApi, 88 call sites).
Transient failures there — network drops ("Failed to send a request to the
Edge Function") and 5xx/429 responses from a stressed backend (DB connection
-pool exhaustion) — surfaced immediately as console errors across dashboard,
usage, access, webhook and device flows, with no recovery path.
Add centralized retry with jittered exponential backoff for transient
failures. Idempotent requests (GET/HEAD) retry up to 2 times by default;
mutations never auto-retry so a retry cannot double-apply. Applies to both
the Cloudflare fetch path and the self-host supabase.functions.invoke path.
Generated-By: PostHog Code
Task-Id: 8cfe4314-5c96-485b-9aed-921b030b50f9
Merging this PR will not alter performance
Comparing Footnotes
|
SonarCloud flagged Math.random() in retryBackoffMs as a PRNG-in-security -context hotspot, failing the quality gate. The value is only backoff jitter, but switch to globalThis.crypto.getRandomValues (the pattern used elsewhere in the app) to clear the gate while keeping the anti-thundering-herd jitter. Generated-By: PostHog Code Task-Id: 8cfe4314-5c96-485b-9aed-921b030b50f9
Keep FunctionsFetchError for retry detection and static supabase imports from main. Co-authored-by: Cursor <cursoragent@cursor.com>
|
|
Hello, I am trying to upload a bundle but getting uploadBundle failed: Edge Function returned a non-2xx status code |



Summary
invokeCapgoApi(88 call sites). When the backend is under stress (DB connection-pool exhaustion →DrizzleQueryError/ pool timeouts), that path failed immediately with no recovery, surfacing as console errors across dashboard load, usage, org access, API keys, webhooks and device flows.Failed to send a request to the Edge Function/Failed to fetchEdge Function returned a non-2xx status code(5xx/429)invokeCapgoApi, covering both the Cloudflare fetch path and the self-hostsupabase.functions.invokepath.retriesoption; default behaviour for mutations is byte-for-byte the same (single attempt).Why: a shared availability regression was producing dozens of silent, immediately-failing requests per day across core workflows; retrying transient failures lets them recover before the user ever sees an error, which should pull the daily failure-log count down from its current baseline.
Note
This is a frontend resilience fix for the symptom (silent, un-retried failures). The upstream trigger — database connection-pool exhaustion — is a separate backend concern and is not addressed here.
Test plan
bun test:unit— addedtests/capgo-api-retry.unit.test.tscovering the retry policy (status classification, idempotent-only defaults, transient-error detection, backoff bounds). All pass.bun lintandbun typecheckclean.Screenshots
Checklist
bun run lint:backend && bun run lint.accordingly.
my tests
Created with PostHog Desktop from this inbox report.
Need help on this PR? Tag
@codesmith-botwith what you need. Autofix is disabled.